A software container is an instance of a user-space running an application within the operating system (OS) of a host device (e.g., a server). Software containers enable operating-system-level virtualization in which the OS kernel allows the existence of multiple isolated software containers.
A software container (or a container) provides an executable environment with a complete filesystem. The filesystem may contain code, runtime, system tools, system libraries, and so on. That is, execution of a software container can be the same regardless of the underlying infrastructure. A Docker is one of the popular existing platforms for creating, migrating, managing, and deploying software containers.
A software container, unlike a virtual machine, does not require or include a separate operating system. Rather, the container relies on the kernel's functionality and uses hardware resources (CPU, memory, I/O, network, etc.) and separate namespaces to isolate the application's view of the operating system. A software container can access the OS kernel's virtualization features either directly or indirectly. For example, Linux kernel can be accessed directly using the libcontainer library or indirectly using the libvirt service.
A demonstrated in FIG. 1, a number of software containers (i.e., the app containers 110-1 through 110-n, hereinafter referred to individually as a container 110, merely for simplicity purposes) can access and share the same OS kernel 120. However, each container 110 can be constrained to only use a defined amount of hardware resources (e.g., CPU, memory, etc.) in the underlying hardware layer 130. Thus, using software containers, hardware resources can be isolated, services can be restricted, and processes can be provisioned to have an almost completely private view of the operating system with their own process ID space, file system structure, and network interfaces.
FIG. 2 illustrates a typical structure of a software container 200. The software container 200 includes a base image 210 and a container layer 220. The base image 220 includes one or more image layers 215-1 through 215-q (hereinafter referred to individually as a layer 215 and collectively as layers 215, merely for simplicity purposes). The layers 215 are read-only layers that represent filesystem differences. That is, the layers 215 are stacked on top of each other to form a base for the container's 200 root filesystem. The layers 215 are read only, and each layer 215 is identified by a randomly generated identifier number of a checksum computed using a hash function.
The base image 210 (and its layers 215) can be shared across different software containers. Thus, only the container layer 220 differentiates between one software container and another. The container layer 220 is a readable and writable layer where all data written to the software container 200 are saved in the container layer 220. When the software container 200 is deleted, the writable container layer 220 is also deleted, and the base image 210 remains unchanged. As such, the multiple software containers 200 can share access to the same base image 210, each of which has its own data state. In the example demonstrated in FIG. 2, the software container 200 is a Docker container (e.g., compliant with the Docker platform).
The popularity of software containers has been increased due to the easy integration with cloud-computing platform (e.g., Amazon® Web Services, Google® Cloud Platform, Microsoft® Azure, etc.). On such platforms, service providers can offer operating systems to run services and applications. With that said, the increasing reliance on software containers increases the need for secured execution.
Various cyber-attacks can be carried out through the execution of a software container. Examples for such cyber-attacks include advanced persistent threats (APTs), zero day attacks, denial-of-service (DoS) or distributed DoS (DDoS) attacks, and so on. An APT attack can cause, for example, data leakage. Zero-day attacks can cause, for example, intrusion of malware to the organization, such as viruses, ransomware, spyware, and the like.
Each software container (and, thus, each application) can be secured separately from other software containers (and applications). Thus, one software container cannot access resources of other software containers. However, the isolation of software containers cannot prevent the execution of malicious code. Malicious activity by software containers can occur through exploitation of legitimate programs or services in a container and improper configuration. Improper configuration may result in, for example, privilege escalations.
Exploitation of legitimate programs may include utilization of named objects created by such programs to perform malicious activity. Typically, a named object can be used for inter-process communication, process synchronization, and the like. Malware, for example, can be programmed to preemptively create a named object before a legitimate program has the opportunity to create one. The malware can exploit the created object to propagate malicious code, leak confidential information, initiate a DoS attack, and so on. Detection of such vulnerabilities occur at runtime only, i.e., during the execution of the software containers.
Another vulnerability is resulted due to sharing the OS kernel 120 among all containers 110 on the same host. This may allow a malicious container to infect or alter a container through the OS kernel 120. Furthermore, malwares can be populated to the containers 110 through the OS kernel 120.
Existing security solutions are not designed to detect such malicious software containers. Such solutions are designed to protect the organization's infrastructure (servers, networks, etc.) against cyber-attacks carried out by external sources. However, existing security solutions are not designed to detect or monitor the operation of software containers, which are an integral part of the organization's infrastructure and are required to carry the organization's applications. Further, such solutions are not designed to detect vulnerabilities in software containers during runtime. For example, an IDS can detect a malware intrusion to a server that is part of the organization's infrastructure from an external source, but the IDS cannot detect any virus/malware intrusion caused by execution of a software container by the server. Such a container is deployed in the server in a legitimate manner. The fact that most software containers are initially hosted in and provided by third party repositories increases vulnerabilities associated with such containers.
It would therefore be therefore advantageous to provide a solution that would secure the execution of software containers.